一個很容易被排在最後面的部門

當一家金融機構開始導入 LLM，優先順序通常長這樣：客服（有明確 KPI）、行銷（有明確產出）、程式開發（工程師自己就會偷用）。法務部往往排在很後面——文件量看起來不大，也沒有直接的營收貢獻。

但如果你用「單位文字的個資密度」來排，順序會完全顛倒。

我在協助一家金融機構規劃資料防護架構時，實際去看了法務部門想丟進模型的三類文件：

契約類：借款契約、保證書、擔保品設定文件。一份契約上有借款人姓名、身分證字號、戶籍地址、聯絡電話、任職單位；有連帶保證人的，同樣一組再來一次；有共同借款人的，再來一次。加上帳號、統一編號、擔保品的地號建號。一份十頁的契約，個資欄位可以超過四十處。

訴訟類：起訴狀、答辯狀、判決書、支付命令。這裡除了兩造當事人，還有第三人——證人、關係人、家屬。而且判決書裡的個資是散在敘述性文字裡的，不是欄位化的：「被告於民國 112 年 3 月間，向原告設於台北市中山區○○路的分行申辦……」。

客訴與調解類：客訴信、金融消費評議申請書、調解筆錄。這一類最麻煩，因為客戶在信裡什麼都會寫。我看過一封客訴信裡同時出現：身分證字號、帳號、就醫紀錄（用來說明為什麼延遲繳款）、家庭經濟狀況、以及另外兩位親屬的姓名電話。

第三類就是所謂的特種個資。個資法第 6 條列的病歷、醫療、基因、性生活、健康檢查、犯罪前科，在法務部的文件裡出現的頻率遠高於任何其他部門。客訴案件本來就常常牽涉到「我生病了」「我先生過世了」「我被詐騙報案中」這類敘述。

為什麼這件事在 LLM 情境下特別危險

法務部門過去也在處理這些文件，但處理方式是人看、人存、在內網流轉。導入 LLM 之後多了三件事：

資料離開了原本的邊界。 就算用的是雲端服務的企業版、就算合約寫了不拿去訓練，資料仍然離開了行內網段。稽核要問的問題會變成：這筆資料現在在哪個國家的哪個資料中心？留存多久？誰有存取權？

存取控制的粒度消失了。 在原本的文件管理系統裡，A 律師只能看 A 案卷。但一個 LLM 應用如果沒有設計好，A 律師的提問可能會撈到 B 案的向量檢索結果。RAG 讓「翻閱別人的卷宗」變得零成本。

輸出是不可預測的。 傳統系統的輸出是查詢結果，你知道會回什麼欄位。LLM 的輸出是生成的，模型可能在摘要裡順手把身分證字號重述一遍，也可能在回答「這類案件通常怎麼判」的時候，把檢索到的其他案件當事人姓名帶出來。

這 30 天要解的問題

用一句話講：讓法務部門能用外部 LLM 處理這些文件，但文件離開行內邊界時不帶個資，回來之後只有被授權的人能還原，而且每一次還原都留得下軌跡。

拆開來是四個子問題，也大致對應這個系列的結構：

1. 偵測：怎麼在中文的非結構化文字裡，可靠地找出所有個資。找不到的那些（False Negative）才是真正會出事的部分。
2. 去識別化：找到之後怎麼處理。遮罩、概化、Token 化各有適用情境，而且只有一種是可逆的。
3. 可控還原：可逆代表有風險。誰能還原、還原什麼範圍、怎麼證明。
4. 驗證：以上三件事怎麼證明它真的有效，而不是自己說有效。這一段會用紅隊的方式打自己的架構。

30 天路線圖

技術棧以 Google Cloud 為主：Sensitive Data Protection 做偵測與去識別化、Cloud KMS 管金鑰、Document AI 處理掃描件、Model Armor 做輸入輸出篩查、Cloud Audit Logs 與 VPC Service Controls 收邊界。中間會穿插幾天我自己做的地端工具，用來對照「自建」跟「雲端服務」在這個場景下各自的取捨。

免責與範圍

本系列的所有場景、文件、人名、數字皆為虛構或合成。文中出現的「王小明」及其身分證字號、帳號一律為測試用假資料。架構討論來自公開標準與我個人的技術判斷，不代表任何特定機構的實際設計或採購內容。

明天先不談技術，先把資料流畫清楚。因為在這種架構裡，你沒畫出來的那一段，就是之後會出事的那一段。

關於作者

我是 Fngi，專注在 AI 資安、LLM 紅隊與 AI 治理框架落地。這個系列的每日更新，以及平常的 AI 攻防筆記、實驗過程與研討會現場，會同步發在 IG：

@aid3fend

有想討論的架構細節或不同意見，留言或私訊都歡迎。